Hardware Description Language (HDL) is a text-based approach to digital logic design through behavioral or structural description of design elements intended for combination and implementation on (1) a field programmable device as in an FPGA or CPLD, (2) a mask programmable device as in a hardwired PGA or ASIC, (3) a system formed from selected electronic hardware components, or (4) any other electronic devices. The HDL-based design methodology requires the user to describe the behavior of a system which may then be simulated (a process referred to as Register Transfer Level (RTL) simulation) to determine whether it will function as desired. The design is then synthesized to create a logical netlist that can be implemented within a particular Programmable Logic Device (PLD) or a particular PLD vendor's device group.
Assuming that neither the synthesis or the design implementation processes alter the behavior of the design, RTL simulation provides the designer with insight into the functionality and behavior of the implemented device before the costly and time consuming synthesis and design implementation processes take place. If accurate, RTL simulation represents a quick and efficient means of validating a design's (and ultimately, a programmed device's) behavior.
However, any assumption that neither the synthesis process or the design implementation process will alter the behavior of a design is, with available HDL tools and simulation methodologies, incorrect. Many device specific features cannot be accurately simulated at the RTL level with available tools. For example, devices such as Field Programmable Gate Arrays (FPGAs) and Complex Programmable Logic Devices (CPLDs) available from Xilinx, Inc., the assignee of the present invention, introduce into the implemented design global signals that a) unconditionally set or reset all of the design's sequential elements (the "global reset" (GR) or "global set/reset" (GSR) network), and b) tristate all of the device's--and therefore all of the design's--output drivers (the "global tristate" (GTS) network). These signals are used by the device's internal configuration controller during initialization and effectively determine a) the device's power-on state, and b) the device's initial interactions with its host system. The GSR 2 and GTS 4 networks on a programmable device 6 are illustrated in FIG. 1.
At the instant power is applied to a PLD, the device will undergo a "wake-up" initialization process that may be as simple as a mere power stabilization time-out, or as complex as reconfiguration over a microprocessor bus. In all cases, a period of time will pass while the device is not performing the function intended by the designer, but is instead executing any required initialization processes before it can assume the user's function. Once these processes are completed, the device switches over to the user's programmed function and user operation begins, as illustrated in the timing diagram of FIG. 2.
The transition from the initialization phase to the user operation phase is known as "start-up" 7 in FIG. 2, and different device families offer a variety of means for controlling the start-up process. For example, while a device is initializing it will typically tristate (electrically isolate) all pins that are not used during the initialization process. This prevents any interaction with the surrounding circuitry before the device assumes its programmed function. The precise moment during start-up when the device activates its input/output (I/O) circuitry and starts to interact with its surrounding circuitry may be critical, and so the ability to control this event is one of several start-up options that are available to the user.
"Start-up" blocks for the global networks on devices produced by Xilinx, Inc., the assignee of the present invention, are illustrated in FIG. 3. An example of usage of STARTUP EX. 1 from FIG. 3 is illustrated in FIG. 4. The start-up block provides the user access to the various functions that are available during the start-up phase of the device's operation, including the global reset and the global tristate signals. The start-up block is a small cell--usually fairly well hidden in one corner of the chip, as shown in FIG. 3--whose pins are accessible via special extensions to the device's general purpose interconnect. Attaching a signal to the GSR/GR or GTS pins of the start-up block introduces that signal to the appropriate global network on the device, as illustrated in FIG. 4.
Globally tristating the I/Os of a device for initialization purposes is achieved by the device's initialization controller asserting a signal known as "global tristate" --an internal signal connected to the output drivers in every I/O cell. Globally tristating overrides any other signal that might be driving an output and causes the output driver to go tristate.
In a similar fashion, a signal known as "global reset" (or "global set/reset" in some architectures) is asserted by the initialization controller during initialization and released during the start-up phase. The function of the global reset signal is to asynchronously hold the registers and latches within the device in the initial states desired by the designer. In the same way that global tristate can be released at the specific instant chosen by the designer, the global reset signal can be released at any time during start-up. Without such a global reset signal, the initial contents of the registers and latches in a programmable device could not be controlled, and designers would be limited to building designs that are insensitive to initial conditions.
In addition to providing a programmable device with a means of initializing itself without inadvertently interacting with the surrounding circuitry and of placing its registers and latches in the initial states required by the designer, the global networks for forwarding these signals remain available once the device has assumed its post-initialization function. For example, if the designer requires the ability to reset a system back to its initial state, the designer can access the global reset signal so that it may be asserted during user operation. In most FPGA and CPLD architectures, the device's internal global reset and global tristate signals are made available to the user so that they may be asserted by signals that come from off-chip, or signals that are generated by user logic within the chip. For example, a reset switch somewhere on a piece of equipment might be used to reset the system back to a known initial state. Different device architectures impose slightly different restrictions on how these two global signals can be used, but essentially, the same functions that are used by the device's internal initialization controller can be accessed by the designer.
Some global signal networks are especially useful in that the reset state of each register or latch is programmable. That is, the user may choose the state that each individual register will assume on assertion of the device's global reset signal. However, as a result of the way in which this selection mechanism is implemented on the silicon in some devices, the user's choice of a register's initial state may dictate the role of that register's asynchronous control pin. For example, if a register is assigned an initial state of High, then the register's asynchronous control input becomes an asynchronous set, and if a register is assigned an initial state of Low, then the register's asynchronous control input becomes an asynchronous clear. Conversely, if a designer requires a register with an asynchronous set input then the register will have an initial state of High, and if a designer requires a register with an asynchronous clear input then the register will have an initial state of Low, as illustrated in FIG. 5.
Thus, in simulating global networks, one must consider the myriad effects accommodating global signals will have on synthesis accuracy. Since global networks which are pre-routed are not made available to most synthesis tools, these tools will not synthesize the correct logical netlist that results in the use of the target device's global networks. Instead, most synthesis tools will interpret the RTL description literally and introduce additional logic into the design with which to implement the desired reset network. Without specific instructions to use the device's global networks, the design implementation tools will be forced to consume general purpose logic and interconnect resources to build functions that the silicon already provides, resulting in inefficient implementation and decreased device utility.
It is therefore paramount that an HDL-based specification of a user methodology relating to the use of global signals not result in designs that are implemented inefficiently (by replicating functionality already present on the target device.) Further, since the capabilities of different synthesis tools vary in terms of their ability to synthesize designs that make use of global resources, a thorough solution should also be insensitive to an individual tool's strengths and weaknesses in this area. Finally, a thorough solution should not compromise the HDL code's portability between different synthesis tools, and different PLD and/or ASIC vendors'products.
These challenges have been dealt with for schematic-based design tools, but remain unaddressed for HDL-based systems. For example, the schematic-based simulation mode for a register or latch differs from that of an AND gate in that it contains a reference to a global reset signal. Similarly, the schematic-based simulation model for an output buffer will contain a reference to a global tristate signal. However, none of these signals will be present on the cell's list of pins when the initial design is entered schematically. Instead, these signals are given "global" status, indicating to the simulator that these signals should be considered to be connected together. The result is that as far as the simulator is concerned, there are two signals in the design that correspond with the global reset and global tristate signals on the target device and designers can simulate these signals as they might any other. In the schematic design environment, these implied connections between all registers, latches and output buffers are understood by the simulator and require no action on the part of the designer.
If the user of a schematic-based system wants to attach a signal to a device's global reset or global tristate network, then the STARTUP cell is added to the design with the appropriate signals attached to its GSR/GR and GTS pins. The schematic-based simulator's simulation model for the STARTUP block is simply a pair of wires from the two pins (GSR/GR and GTS) to the simulator's two global nets, as illustrated in FIG. 6.
The simulation model for the schematic STARTUP block is behaviorally null. Instead, the signals for the global networks of GSR/GR and GTS pins are forced by the simulator's stimulus tool directly and not by a model's output signal. Further, the design implementation tools recognize the schematic STARTUP block as a genuine function on the device silicon and will route the user's signals through the general purpose interconnect to the appropriate access points on the silicon. Thus, with schematic-based tools, the netlist that's written out by the design tool will contain only the details of the user signals that drive the STARTUP block's GSR/GR and GTS pins. The global simulation signals will not be written out into the netlist, and the design implementation tools will not attempt to implement them by routing them through general purpose interconnect. Under these circumstances, the design should simulate and behave identically, as a result of the advantages of the schematic design environment over the available HDL design environment.
All of the functions relating to global networks are required by the HDL designer. However, there is currently no support for global networks in HDL design environments. One complication is the fact that when implemented, a design will be subject to the effects of the target device's global signals regardless of whether their effect was described in the HDL. While this may seem a trivial difference, the repercussions are significant. Whenever the designer describes a sequential function in HDL, every aspect of that function must be explicitly described in the code in order to be sure that no ambiguity arises about the types of flip-flops that should be synthesized. It is therefore impossible to define the initial states of sequential elements within the language limitations imposed by most synthesis tools.
Since the definition of a sequential element's initial, or power-on, state is of some importance, some synthesis tools invite the user to issue commands (in the synthesis tool's own command syntax) with which to assign initial states to sequential elements. However, this is unsatisfactory since such assignments would be made outside of the designer's HDL code, and the code by itself would no longer be intrinsically complete. Such measures also impact a design's portability between synthesis tools since although the HDL code would remain standard, the means of assigning initial states to sequential elements would not.
As stated above and illustrated in FIG. 5, on Xilinx, Inc. FPGAs and CPLDs if registers and latches are required to have an asynchronous clear input, their initial state is Low, and similarly, if they are required to have an asynchronous set input, their initial state is High. However, even provided this assumption, it is still possible to write ambiguous HDL from the simulation and synthesis standpoints. Though these problems can be mitigated somewhat by assigning the registers initial values, there remains a significant chasm between the synthesis and simulation worlds for HDL-based designs since these initial values are ignored for synthesis. The risk of a design's simulated behavior and its real behavior differing is very high and must be accepted unless a design methodology is provided which eliminates the risk.
As can be seen in FIG. 7, once the automated place and route tools have implemented a design, they can write out an HDL netlist that describes the physical implementation of the design and a Standard Delay Format (SDF) data file that describes the design's timing. With these two sources of data, the simulator can be made to model the device's genuine behavior very accurately. However, in order to accurately model the device's initialization behavior, the netlist that's written out by the tools must include a description of the device's global reset and global tristate networks. The presence of these signals in the netlist permits the designer to a) simulate the device's power-on or reconfiguration behavior, and b) simulate the effect of the user asserting either of these signals from an external port or internal logic.
Most HDLs (including VHDL) require the declaration of ports for all signals in a module which are to be monitored, stimulated or otherwise accessed. Inclusion of the global reset and global tristate nets in the back-annotation netlist is the user's means of initializing the simulation, so it is therefore necessary to add ports to the back-annotation netlist through which the user may access these global signals. However, the addition of these ports makes the pre- and post-implementation versions of the design different and the user's original test vectors (or testbench) will no longer be applicable to both versions of the design (since the port lists for the two versions of the design are different, the "socket" in the testbench will only match one of them, so the testbench is only applicable to one version of the design).
This fact alone is enough to rule out the use of available HDL-based tools in many existing design environments, since the only means the designer has to confidently establish whether the implemented design works as intended is through the consistent application of test vectors. To require that the designer keep two versions of the test vectors (regardless of how trivial the differences are) in order to test pre- and post-implementation versions of a design is unrealistic and generates considerable discomfort (and therefore diminished use) among the user community.
There is therefore considerable need in the art for a design tool and method of accurately simulating HDL-based designs in a manner which will take into account the various global signal networks utilized by available programmable devices without burdening the user with otherwise unnecessary limitations.